Amendments to the Specification 
Page 1. Amend paragraph 0001 as follows: 

[0002] Reference may be made in this specification (using bracketed numbers) to the 
publications listed in Appendix B, available either in printed form or online and incorporated 
herein by refereiice.-^^efemeer 



6891-00, March 2003. 
■S,--Wa<^-W^j¥kmg Draft, "SOAP Version 1.2 Part 2: Adjuncts", June 2 6, 2002. 
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Pages 2-3. Amend paragraph 0004 as follows: 

[0004] In a service-oriented architecture such as Web services, a service provider can provide a 
number of transport protocols used for binding to access a service. This is done in order to 
provide better quality-of- service (QOS) features for the clients. One example of this binding is a 
transport binding for a service using HOP instead of SOAP/HTTP for better performance. (For 
these and other acronyms, see the glossary in .^vvtM^-- \ ^ /-n \ below. SOAP is 
described in more detail in references 3-6 and 12 of .Appendix B,) The service provider defines 
this binding information in a WSDL document at the time of the service deployment and initiates 
the server-side framework (stubs/JMS listener etc.) to support those bindings. The service 
skeletons are created to handle incoming requests in a binding- specific manner and convert the 
incoming requests to the platform-specific service invocation model. There can be a number of 
binding protocol models (SOAP/HTTP, IPC, nOP, RMI, SOAP/JMS etc.) that can be created 
based on such criteria as performance, interoperabihty, service container capabilities and QOS 
requirements. The client who uses the service can get hold of the WSDL document for the 
service from some registries (UDDI) or from the service itself (through HTTP GET) and 
evaluate the WSDL document. The client can generate static stubs or can dynamically introspect 
the WSDL document for the service invocation. This results in a client with a number of 
transport-protocol binding information proxies, from which the client needs to select one to 
invoke the service. 

Page 6. Amend paragraph 0016 as follows: 

[0016] WMle-#^e^a¥eMieB4 a prefer ab ly implemented in software, the Tlie invention may be 
implemented in hardwarev ^f&ftwai=e; or seme as a combination of hardware and software-4fee--iw0. 
When implemented m~as a combination of hmdware and software, i*-the softwai-e part of the 
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combination may take the form of a program storage device (such as a magnetic or optical disk 
or semiconductor memory) readable by a machine, tangibly embodying a program of instructions 
executable by the machine to perform defined method steps. 

Page 5. Amend paragraph 0015 as follows: 

The present invention does not address service-specific binding requirements to achieve certain 
QOS features. This includes binding addressing scheme, message format, encoding, message 
style (DOC/RPC), invocation model and other binding-specific QOS (co-relation, transaction 

and security etc). In addition, the present invention imposes no programmatic definition on 
binding usage. The client-side framework selects these bindings, and clients are independent of 
this binding selection. An implementation can be a WSIF framework (provides a number of 
bindings for Web services) that can be used along with a JAX-RPC handler (binding selector) for 
Web service binding selection. (JAX-i^LP(;] is described in more detail in reference 9 of Appendix 
B.) 

Pages 11-12. Amend paragraph 0043 as follows: 

[0043] The negotiation protocol is a preferably XML-based protocol for supporting a binding 
negotiation between a client and the service. (XML. is described in more detail in references 7-8 
of Appendix B.) While the negotiation protocol need not use any particular language, it may 
have these components: (a) a negotiation action and conversation header; (b) negotiation data; 
and (c) profiles to help the conversation. Preferably, the protocol also has extensibility features to 
support message extensions. The negotiation action may specify actions like list bindings, select 
binding, use binding, binding property enumeration, etc. The conversation header may contain 
correlation information on messages. The negotiation data includes the data for the actions 
described above. These are the profiles to help binding selection. This can include client/service 
container information, user-defined requirements and any other information that can help binding 
selection. The profiles may be in any data format, including binary data. In the case of SOAP, 
SOAP attachments [12] (which are MIME-type attachments) may be used to send these MIME- 
based profiles. 
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Page 17. Amend the title as follows: 

APPENDIX A: ABBREVIATIONS AND ACRONYMS 

After page 17. Add the following new appendix: 
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